Universal forms engine

ABSTRACT

A forms engine allows data sharing between customizable on-line forms, such as college admissions applications. Before applying, an applicant opens an account with a third party application servicer. After the applicant completes an application for one institution, the data is saved in a data base and automatically populates fields in subsequent application forms. The form for each institution is created from a form description file. Each form is branded for its institution and forms for different institutions differ in appearance and content so that the presence of the third party servicer is transparent to the applicant.  
     The system is extensible without programming, allowing new applicant attributes to be readily incorporated into the system and allowing the content and appearance of the application to be readily changed by changing the description file. The use of aliases for applicant attributes permits data to be readily shared between forms even though labeled and arranged differently on different forms. Information stored about each attribute allows the specification of data validation rules and data sharing and grouping rules, as well as dependency rules that permit application page content to depend on applicant&#39;s responses on a previous page.

RELATED APPLICATIONS

[0001] This application claims priority for U.S. Provisional Patentapplication No. 60/088,123, filed Jun. 4, 1998.

FIELD OF THE INVENTION

[0002] This invention relates to a computer implemented method andapparatus for processing forms and, in particular, to a method andapparatus for processing customizable application forms that shareinformation from an extensible database.

BACKGROUND OF THE INVENTION

[0003] The processing of college admission application forms describedbelow is illustrative of the current state of forms processing. Studentsapplying to colleges and universities typically complete a separatepaper application for each institution to which they seek admission.Each application is then mailed to the corresponding institution alongwith an application fee.

[0004] Many institutions would like to simplify the application processby allowing students to apply over the Internet. Although an Internetapplication allows an institution to process the application informationelectronically, a student is required to re-enter the same informationfor each subsequent application to a different institution or to thesame institution for a different academic term. Moreover, if theinstitution wishes to change the application form, the institution musttypically revise the source code that creates the application form,thereby making changes to the application form expensive andinconvenient.

[0005] One could reduce redundancy in the application process byallowing students to complete a single, generic application provided bya third party who would then transmit the application to any designatedinstitution. Such systems, however, would make it impossible forinstitutions to customize their applications form. In an environmentwhere schools are competing for top students, the image that a schoolprojects to potential students is important, and a customizedapplication can help project the image that the school wishes to create.The questions that a school asks on its application reflect the valuesof the institution. Many schools want information different from thatwhich would be on a generic form. Thus, it is unacceptable to manyinstitutions to use a generic application form.

[0006] Most institutions continue, therefore, to use primarily paperapplications or their own on-line applications, with the disadvantagesdescribed above. Moreover, the institution must then process theapplication fee for on-line applications, which may require that theinstitution have some expertise in electronic commerce.

SUMMARY OF THE INVENTION

[0007] Accordingly, it is an object of the present invention to providean improved method of processing forms.

[0008] It is yet another object of the present invention to provide sucha method that allows data sharing between customizable forms, thecustomization including branding of forms to specific institutions.

[0009] It is yet a further object of the invention to provide such amethod that uses an extensible data-sharing database.

[0010] It is still another object of the present invention to provide animproved method of processing admissions applications.

[0011] The present invention comprises a universal forms engine thatpermits the creation and processing of customizable electronic forms andselective sharing of information between the customized forms. A userthus enters data only once, and the data is shared through an extensibledatabase between disparate forms. The forms are completed by a user overa computer network and information from each completed form is forwardedto the appropriate entity over a computer network. The ability of theforms engine to present a form for user input, to receive data from theuser, and to provide the data to the appropriate entity is independentof the computing platform of the user and the entity. Any feesassociated with the forms can be processed electronically over acomputer network together with the forms.

[0012] The invention thus creates forms, parses data on forms, storesdata, retrieves the data, and deploys the data onto other forms. Asadditional forms are completed and additional information becomes partof the database, the amount of information that must be manually enteredon new forms decreases because the new forms are automatically populatedwith the previously entered data.

[0013] A form is considered to be essentially a container for data andimplies an associated process. The forms engine integrates the form, thedata, and the processing regardless of the appearance of the form, thetype or significance of the data, and the processing that followscollection of the data.

[0014] Metadata, that is, information that characterizes the applicantdata is also stored. For example, in one embodiment, an attribute tabledescribes characteristics, such as permissible values and accessibilityto various institution personnel, of applicant attribute data. Inanother embodiment, such properties of the applicant attributes arestored in XML files. Storing metadata provides greater control over thedata validation, sharing between forms, grouping, and access.

[0015] User information and application information are abstracted fromthe coding, that is, the user information and application information isstored in a way that allows the application information and the userinformation to be changed without reprogramming. This abstraction allowsthe set of user data to be extended without reprogramming, allows theuser data to be displayed in different formats in differentapplications, allows the data to be validated to ensure that it can beused by the institutions, and eases access to the information over theWeb by institutions. Abstracting the application information allows theapplication itself to readily changed, and allows changes, such aschanges to application dates, to be made by the institutions themselves.The abstracted information is saved, for example, in a relationaldatabase or in an XML file.

[0016] The subject matter of the present invention is particularlypointed out and distinctly claimed in the concluding portion of thisspecification. However, both the organization and method of operation,together with further advantages and objects thereof, may best beunderstood by reference to the following description taken in connectionwith accompanying drawings wherein like reference characters refer tolike elements.

BRIEF DESCRIPTION OF THE DRAWINGS

[0017]FIG. 1 shows a network through which applicants, a servicer, andinstitutions are connected in a preferred embodiment of the invention

[0018]FIG. 2 shows an entry web page presented to an applicant of FIG. 1

[0019]FIG. 3 shows a web page showing the results of an on-line collegesearch that provided the link to the entry web page of FIG. 2.

[0020]FIG. 4 shows a web page for creating a new account with theservicer of FIG. 1

[0021]FIG. 5 is a diagram showing schematically how accounts are createdin a preferred embodiment of the present invention.

[0022]FIGS. 6a-6 d show a web page used to supply directions andinformation to the applicant of FIG. 1.

[0023]FIG. 7 shows an applications options page that provides theapplicant with links to an application instruction page,

[0024]FIGS. 8a-8 d shows an application instruction page for an on-lineapplication.

[0025]FIG. 9a-9 c shows the first page of an on-line admissionsapplication

[0026]FIG. 10a-10 c shows the second page of an on-line admissionsapplication

[0027]FIG. 11a and 11 b shows the third page of an on-line admissionsapplication

[0028]FIG. 12a-12 d shows the fourth page of an on-line admissionsapplication

[0029]FIG. 13 is a diagram showing schematically the interactionsbetween the applicant, the forms engine and the applicant databaseduring initial access of an application form.

[0030]FIG. 14 is a diagram showing schematically the interactionsbetween the applicant, the forms engine and the applicant database asdata is posted from an application form.

[0031]FIG. 15 shows a flowchart of the interactions shown in FIGS. 13and 14.

[0032]FIG. 16 shows the steps shows the steps that occur in a preferredembodiment when an applicant contacts the forms engine.

[0033]FIG. 17 shows the “back-end” states available during applicationprocessing.

[0034]FIG. 18 is a simplified example of classes used in anobject-oriented programming implementation of the invention.

DETAILED DESCRIPTION

[0035] The system according to a preferred embodiment of the presentinvention comprises a forms engine that processes applications foradmission to institutions. The preferred embodiment, which is operatedby a third party application servicer, uses relational databases forstoring information and communicates with applicants and institutionsover the World Wide Web. The invention is not limited, however, to theprocessing of any particular type of form or to the use of anyparticular network or database.

[0036] Overview of a Preferred Embodiment

[0037]FIG. 1 shows multiple applicant computers 14 that communicate witha server 16 through the portion of the Internet 18 known as the WorldWide Web (the Web). A typical applicant computer 14 comprises a personalcomputer, such as a Pentium-based personal computer using aWindows-based operating system and running a commercially available WebBrowser, such as Netscape Navigator or Internet Explorer. In a preferredembodiment, applicant computers 14 can use an older, text-based browser,because processing, such as error checking, is performed at server 16,rather than at the client browser.

[0038] Server 16 is a computer, such as a Sun Solaris UltraSparc Server,that is executing a forms engine of the present invention, as well asWeb server software that coordinates communications with visitors to theform engine Web site. Information and forms transferred from server 16are typically formatted in a hypertext mark-up language (HTML) and caninclude text, programs, graphics, video, and audio portions. Server 16is preferably operated by a third party application servicer 24 and isconnected to secure data storage 26. Multiple institution computer 28,operated by institutions, such as colleges or universities that requireadmissions applications, also communicates with server 16 over theInternet 18.

[0039] Although the preferred embodiment of the invention is implementedusing an Internet Web site, the invention is not limited to anyparticular type of computer or computer network. By making theapplications available over the Web, any applicant with a Web browsercan apply electronically. On-line application also allows theapplication fee to be processed on-line, so that credit cardsettlements, electronic bank withdrawals, and other payment methods canbe performed more efficiently, and the settlement can be easilyfacilitated by the third party that operates the application formsengine to which multiple institutions subscribe.

[0040]FIG. 2 shows an entry page 36 that is presented to an applicantwho has accessed server 16 of FIG. 1. In a preferred embodiment, entrypage 36, as well as all other pages presented to the applicant, ispresented as an HTML page. Pages on which the applicant entersinformation use the HTML <FORM> tag. The HTML form posts information toserver 16, which executes a common gateway interface (CGI) programspecified by the form to process the received information. The CGIprogram is preferably written in Perl, C, C++, Java, or another languagethat supports CGI. The CGI program accesses a database that includesinformation about the customized application form and about theapplicant. The database is preferably a relational database that isaccessed using a structured query language through a database managementsystem, such as Informix®, by Informix Software, Inc., based in MenloPark, Calif. The invention is not limited to a particular implementationtechnology. The implementation details of the invention are expected tochange as computer technology evolves.

[0041] Entry page 36 can be accessed from, and can be in the same styleas, an institution's own world wide web site. Entry page 36 can also beaccessed from other links, for example, by a link 38 (FIG. 3) on aresults web page 40 from an on-line college search, such as theCollegeNET™ System, operated by the assignee of the present invention.Entry page 36 is branded with a logotype 42 branding the application asbelonging to the institution to which it is directed, although theapplication is preferably hosted by a third party to ease data sharingacross institutions and electronic processing of application fees.

[0042] Before accessing an application from entry page 36, eachapplicant is required to have an account with the third party servicer24. Entry page 36 includes a link 52 for creating a new account. FIG. 4shows a web page form 54 that is presented to the applicant to create anew account. Although the account is with third party servicer 24 andcan be used to apply to many institutions, web page form 54 is brandedwith the logotype 42 of the institution to which the applicant isapplying. Thus, it is transparent to the applicant that the applicationis being processed by third party servicer 24.

[0043]FIG. 5 shows schematically the actions that comprise the accountcreation process 56 required to create an account. The applicant uses aweb client 58, such as Netscape Navigator, to enter personalinformation, such as name, address, e-mail address, and a user name andpassword for accessing the system. The password is encrypted and saved,along with the user name, in a password database 60 connected withserver 16 (FIG. 1) and user information is saved in an applicantdatabase 62, which databases comprise database 26.

[0044] Entry page 36 (FIG. 2) also provides an information link 68 toprovide the application with directions and information. FIGS. 6a-6 dshow a preferred information web page 70 that is returned to the user inresponse to a request for information. Web page 70 is also branded withlogotype 42 indicating the institution to which the application isdirected. Web page 70 includes an application option page link 72 (FIG.6d) to the actual application, as does entry page 36. Entry page alsoincludes a link 74 to the user's personal log page. The personal logdescribes the status of all applications the user has worked on,including applications that have been submitted and applications thatare in various stages of completion. Entry page 36 also includes a link76 for changing a user's password.

[0045]FIG. 7 shows an applications options page 82 that provides anapplication instruction page link 84, an application link 86, and links92 to supplemental forms, such as a counselor's report or teacherrecommendation forms, that accompany an application. FIGS. 8a-8 d showsapplication instructions 94 reached from application link 86.

[0046]FIGS. 9a-9 c show the first page of an electronic, on-lineadmissions application 96 that is customized in content and appearancefor a particular institution. As shown in FIG. 9a, each application isindividually “branded,” that is, it carries the name and logotype 42 ofthe institution and appears in a style that is representative of theinstitution. Thus, it is transparent to the applicant that a third partyis servicing the application, that is, the applicant may not even beaware that the application is processed by a third party servicer. Inaccordance with the invention, the third party servicer providescustomized forms for each participating institution, and data is sharedbetween the customized applications. Information that had previouslybeen entered in connection with prior applications to any institution isautomatically inserted into the customized form. Information entered bythe applicant onto the application form is stored in an applicantdatabase for automatic insertion into subsequent applications by thatapplicant. The HTML source code for page 1 is attached in Appendix 1.FIGS. 10a-10 c, FIGS. 11a-11 b, and FIGS. 12a-12 d show additional pagesof application 96.

[0047]FIG. 13 shows schematically the interrelationship when supplying aform pages to an applicant between a forms engine 104 of the presentinvention, applicant database 62, password database 60, and web browserclient 58 running on applicant computer 14. FIG. 13 shows that formsengine 104, preferably implemented as a CGI program, performs fourprimary functions. When the applicant requests an application form for aparticular institution and the request is authenticated by comparing thepassword with the password in the password database 60, forms engine 104retrieves user information regarding the status of applications that arepending or completed.

[0048] Forms engine 104 then generates a customized application formbased upon an application description in an application data file 108.Forms engine 104 then retrieves user data that was entered in previousapplications and stored in the applicant database 62, and merges theuser data into the current application, which is then returned to theapplicant as an HTML form. The applicant then enters any requestedinformation that was not automatically inserted from the database.

[0049] Application 96 includes fields for the applicant to enter thespecific information the institution requests of its applicants. Theinformation is requested in a format chosen by the institution. Thestyle and content of the customized application expresses the valuesheld by the institution. The customized content of each applicationallows the school to obtain specific information that it chooses tocharacterize its applicant pool, including factors that it believes maycorrelate with student success at the particular institution.

[0050]FIG. 14 shows schematically the interactions between forms engine104, applicant database 62, and web client 58 with respect to formsengine 104 receiving data posted from the applicant. Forms engine 104performs a “front-end” validation on the posted data 118. Datavalidation is explained in detail below. If the data fail validation, adata correction page is sent to the applicant. If the data pass firststage validation, the next application page is prepared by mergingapplicant information from the applicant database 62 with forminformation in application data file 108 and sending the resulting HTMLapplication page to the applicant.

[0051] After all the pages have passed first stage validation and theapplicant attempts to submit the completed application to theinstitution, a second stage validation is performed. If the second stagevalidation is successful, user data 120 is written to the applicantdatabase 62 and payment scripts 122 are executed in which the user isgiven an option to select any one of several of on-line payment methods.Credit card information is verified from a credit card database 124.After the information on the application is validated, it is transferredto the institution in a data format specified by the institution. Theinformation is also stored for use in subsequent applications in anapplicant database 62, which is independent of the institution.

[0052]FIG. 15 is a flowchart showing the products at each step ofprocessing by forms engine 104 described in FIGS. 13 and 14. Optionalsteps are shown in dashed lines. FIG. 15 shows that an applicant 126contacts forms engine 104 by a browser request for an application.Before presenting an application page to an applicant, forms engine 104determines the state of the application process, and only presentsappropriate pages to the applicant. For example, most institutions haveapplication date windows during which applications, whether electronicor paper, for a particular term are accepted. The forms engine verifiesthat the application is being submitted within the allowed window.Unlike pre-printed paper applications, however, the invention providesthe schools the flexibility of easily changing the application datewindow, so that the time to apply can be extended if the institutionwants to receive additional applications.

[0053] Forms engine 104 uses data from the appropriate application datafile 108 (FIG. 14) and previously entered user data to generate a pageof a form 128. Data 130 is entered on the form page, by the applicant orfrom the database, and the page undergoes a first stage data validation136 upon being posted by the applicant. A correction page form issubmitted to the applicant each time a data validation fails, and thedata is saved to the database upon successful validation. The process isrepeated for additional pages until the form is completed and theapplicant submits the form.

[0054] When the applicant indicates that the application is ready to besubmitted to the institution, a final, more thorough validation 136,known as second stage validation, is performed on the data. Second stagevalidation ensures that information required by the specific institutionto which the application is directed is present and that the informationmeets certain content criteria specified by the institution. The datavalidation is customized for each institution. If the application failssecond stage validation, a data correction page is returned to theapplicant. The validated, submittable data 140 is stored in applicantdatabase 62 in connection with the application. The data is thenprocessed and transformed 142 as described below in connection withaliases, and saved for use in other forms that the applicant maycomplete in the future. A payment 148 is then processed and applicationtransaction processing 150 is completed. The forms engine then convertsthe application information into a form compatible with theinstitution's internal databases and delivers the information 152 to theinstitution's database 154.

[0055] When the applicant subsequently applies to a differentinstitution or to a different program within the same institution, a newapplication, customized for the different institution, is presented tothe applicant. Information that was entered onto previously submittedapplications is retrieved from the database and presented to theapplicant as populated fields of the new application, so that theapplicant is not required to enter information more than once. Theapplicant can change the values in a pre-populated field if desired andthe new values are saved for use in subsequent applications.

[0056] As described in more detail below, information about theapplicants is maintained as a set of attributes, each attributecorresponding to database fields. If an institution chooses to includein its application a request for an applicant attribute that does notcorrespond to one included in the database, the database is easilyextended to include the new applicant attributes without reprogrammingthe forms engine. Once the new attribute is added to the database, it isavailable for automatic inclusion in all subsequent applications.

[0057] In the preferred embodiment, each attribute used to characterizeapplicants has a unique identifier or alias. The unique identifierallows the engine to recognize when the same information is beingdescribed by different labels or entered in a different format ondifferent application forms. The information can then be saved properlyand inserted into subsequent applications, regardless of differences inthe entry format and labels in the first and subsequent applications.Thus, the variables can be universal and unique data elements havingdifferent names can be shared among applications.

[0058] For example, one institution on its application may refer anapplicants last name as a “family name” while another institution mayrefer to the last name as “surname” or a “last name,” yet the formsengine would share the data properly between such application forms. Asanother example, if a first application form requests multiplechoice-type information in the form of radio buttons and the second formrequests the same information in the form of a pull-down menu,information entered on the first form in the radio buttons would appearin a pull-down menu box on the second form.

[0059] While providing the institution flexibility to designate andrequest the information any way it chooses on its customizedapplication, the information is retrievable onto subsequent applicationsregardless of how the subsequent applications label or display theinformation. The forms engine of the present invention can thus shareinformation across applications, regardless of how the information isexpressed in a particular application, unless the data has beendesignated as described below as private to a particular application andnot shareable.

[0060] Each applicant attribute is characterized by one or moreproperties. The properties that characterize an applicants' attributescan specify, for example, whether and under what conditions theattribute data can be shared between forms, whether the attribute is auniversally required field, or whether the attribute is specific to aparticular geographic region. For example, an attribute named“California Driver License Number” is applicable only to institutions inCalifornia. Other information may be applicable to all institutionswithin a region but not to other institutions. Some applicant attributesare applicable only to institutions in a particular school system.Individual pieces of information can also be grouped and properties canbe specified for the groups. The application can also includeinformation that designates the routing of the information to groups,such as financial aid officers, within the institution.

[0061] The invention not only allows an application to be customized foreach institution, it allows the information submitted by the applicantto be transmitted to each institution in any data format that theinstitution requests so the institution is not required to convert thedata to a useable format. For example, multiple fields, such as firstname and last name, may be combined into a single field, and the datafields may be delimited by a delimiter specified by the institution.Data may also be transmitted to the institution, for example, asname-value pairs, as fixed records, in EDI, or printable PDF format.Thus, the applicant information is entered in a customizable form on abrowser running on any type of computer platform and stored at thirdparty servicer 24 in a database. The information in the database is thenreloadable into another customizable application form for a differentinstitution. The information is also transmittable to an institution inits preferred format regardless of the platform used by the institutionto process the information.

[0062] After an application is sent to an institution, the informationremains available in the database of the third party servicer forfurther analysis by the institution. The institution can, for example,sort or view applicants based upon attributes such as test scores, gradepoint average, participation in sports, or musical talent. Moreover,each applicant attribute has a property that can be used to specify whoin the institution has access to the attribute for the purpose ofuploading the information or of processing the information tocharacterize the applicant pool. For example, parts of an applicationdealing with academic background may be viewable by academicdepartments, whereas more personal information may be viewable only byschool administrators.

[0063] A preferred implementation of the invention comprises a singleforms engine program, a single applicant database, including informationon all applicants, and one application data file for each differentapplication of each the participating institutions. The application datafile describes the format of each application, and the forms enginedisplays information from the database in the format prescribed by theapplication data file.

[0064] The applicant database can be extended to include new attributeswithout making any changes to the forms engine program or to theapplication files of institutions that chose not to include the newdata. The forms engine automatically uses the application data file toproduce the requested application in HTML format for display on theapplicant's browser. The application description file can be easilymodified, for example, to change labels or to add additional fields. Theappearance of the application for each institution can be changed bychanging its application description file, without reprogramming theforms engine. The completed application is transmitted to theinstitution with the data in any format that the institution prefers.The institution can therefore upload the data directly into itsapplicant or student information system database, merging theinformation seamlessly into their existing work flow, thereby avoidingthe additional expense and errors of re-keyboarding the information. Theforms engine thus has the capability of outputting applicationinformation universally across platforms.

[0065] A transactions database table and a transactions operations tabletrack completed transactions and operations to assist the engine inmaintaining information about the state of each application, so thatonly appropriate pages are presented to the applicant. These tables alsoallow the applicant to track the progress of his or her applications andonline payment.

Database Structure

[0066] The tables described below are used in a preferred collegeadmission forms processing system. The invention can be used forprocessing many different types of forms without departing from thescope of the invention, and skilled persons will recognize thatdifferent database structures will be required in differentapplications.

Attribute Table

[0067] A first database table, the Attribute Table, includes a list ofall attributes that can be used to describe an applicant. The AttributeTable thus defines the variable space for the entire system. Eachattribute, such as Name, Social Security Number, and SAT score, isrepresented by one row of the Attribute Table and is identified by aunique Attribute Identification Number. The Attribute Table includesproperties of each attribute, such as whether the attribute is arequired field for first stage validation (explained below) and whetherthe attribute is part of a data group, such as a geographical region oran institutional group. The Attribute Table also includes references tofirst stage validation rules, if any, for each attributes. The AttributeTable does not include values of the attribute for any particularapplicant.

User Attribute Table

[0068] The values assigned to attributes for individual applicants arestored in a User Attributes Table. Each row of the table includes a UserIdentification, an Attribute Identification Number, a sequence for theAttribute Identification Number, and a data value. When an applicantenters information on an application page on the Web and posts the formto the server, the information entered by the applicant is stored in theUser Attribute Table after first stage validation. The form is postedwhen the applicant switches to another page or when the applicantindicates that the information is to be saved. An applicant may changethe values of an attribute from one application to another. For example,an applicant may change his or her SAT scores to reflect new testresults.

[0069] The User Attribute Table always includes the latest informationthat an applicant had entered and is used to supply information for newapplications. When the user calls up an application to complete, data isread from the User Attribute Table. When a new application includesattributes that were not requested by any application that the userpreviously completed, a new row corresponding to the new attribute isinserted into the User Attribute Table. Preferably a single UserAttribute Table includes the attribute information on all applicants inthe systems.

User Attribute Sent Table

[0070] After an application is completed and it passes second stagevalidation, the information contained in the application is stored in aUser Attributes Sent Table, which represents a snapshot of the submittedapplication. The structure of the User Attribute Sent Table is verysimilar to that of the User Attribute Table. The primary key of the UserAttribute Table is a user identifier (the users log-on name), whereasthe primary key of the User Attribute Sent Table is a TransactionIdentifier, which identifies a unique combination of user, application,and application term. Thus, there can be multiple records for a singleuser in the User Attribute Sent Table if the user has submitted multipleapplications or the same application for different application terms.

[0071] The Transaction Identifier is the same identifier used in theTransactions Table, described below. Thus, one can scan the TransactionsTable for Transaction Identifiers that correspond to applications thatare shown as having been submitted, and then use those identifiers tolook up data related to those applications in the User Attribute Senttable.

[0072] Second stage validation is performed before writing a record intothe User Attribute Sent Table and may, for example, combine fields suchas last name and first name into a single field. Thus, the UserAttribute Sent table shows exactly what was sent to the institution, andtherefore includes a record for each application that was completed by auser. To review what data was sent, the institution reviews informationderived from the records in the User Attribute Sent Table, which arethen put into a format requested by the institution.

Applications Table

[0073] Each customized application is represented within an ApplicationsTable, which defines the data set for each application. Each row in theApplications Table pertains to one attribute in a specific applicationand includes information such as an Application Identification Number,Attribute Identification Number, Attribute Sequence Number within theapplication, any second stage validation rules (described below), theIdentification Number of the institution to which the applicationbelongs, etc.

Application Data File

[0074] The Application Data File is a specially formatted text file thatacts as an application description. It is a series of “directives” andoptional arguments which the forms engine parses to build the HTML formand to merge in user data. The directives are interpreted by means of alook-up in a data structure that stores the directive interpretations.For example, a line in the Application Data File may be “SS_NUM.” Uponencountering the line, the forms engine will look into a data structureto interpret SS₁₃ NUM. SS₁₃ NUM may mean, for example, to display a textbox with a label that reads “Enter Your Social Security Number” and toput the previously supplied value for social security number (stored inthe User Attribute Table) into the text box. SS₁₃ NUM may also prescribea minimum length, maximum length, and call a function that creates thetext input box. The directive could also set flags that indicate aparticular state for the application. The Application Data File canoptionally supply arguments to directives. Arguments may, for example,instruct the forms engine to apply specific labels or to overridedefault values, so that the label or format for entering the data can becustomized. The information in the Application Data File couldalternatively be included in the Applications Table.

[0075] In an alternative embodiment, rather than having the applicationinformation stored as directives and building the application whenever astudent invokes it on-line, the application is built by a pre-processorutility that is run once to produce an “application template” with aregularized syntax. In other words, an Application Data File entry suchas “SS_NUM” is replaced by a template line such as “SS_NUM|ITEXT|SocialSecurity Number: |11|11”.

[0076] In the previously described embodiment, the Application Data Filelines represent function calls with optional arguments. The forms engineexecutes these function calls, which in turn execute aform-element-producing function like “ITEXT” which produces a text box.Thus, the forms engine not only needs to have available hundreds offunctions, it also has to do two (or more) layers of function executionfor each line in the Application Data File.

[0077] In the alternative embodiment, most of this processing isperformed off-line during the application development phase, and theresults of the processing is saved in the template file. The on-lineforms engine then pulls in this “pre-digested” template file. Each lineof the template file is a pipe (“|”) separated list of: (1) variablename; (2) form element [for example, form element ITEXT is textbox,IRADIO is radio button(s), etc.]; (3) question label; and (4) argumentsneeded by the form element function.

[0078] Whereas the forms engine in the first embodiment is analogous toan interpreter, executing a shell script, the template in the secondembodiment is analogous to compiled code. The pre-processing isanalogous to a compilation phase, and the output template file isanalogous to a binary object. It is composed of instructions to theengine, like compiled code is composed of instructions to the CPU,whereas the bulk of the forms engine in the first embodiment comprisescode to do the interpretation, the forms engine in the second embodimenthas a very small instruction set: basically one instruction per formelement, plus a handful of special instructions.

[0079] The template file gives the application developer absolutefreedom to quickly update the application with no need to rewrite or addprogram code to the forms engine. Use of templates also dramaticallyreduces the number of functions needed by the engine, as well as theexecution overhead.

[0080] The template file can be in the form of specially tagged HTML;that is, instead of a line-by-line set of directives, the template canlook like HTML with embedded special tags representing the formelement/variable/value to interpolate.

[0081] Below is an example, simplified for clarity, of a part of atemplate represented in a specially tagged HTML: <H1>BiographicalInformation</H1> <OL> <LI> <QUESTION ATTR_ID=“53”ARGS=“SS_NUM|ITEXT|11|11” VALRULE=“Req( );Int(- ,);Len(9)”>Please enteryour Social Security Number: </QUESTION> </LI> <LI> <QUESTIONATTR_ID=“106” ARGS=“BIRTH_DATE|DATEMDY” VALRULE=“Req( )”>Please enteryour birth date (MMDDYY): </QUESTION> </LI> </OL>

[0082] To process the template, the forms engine need only look for<QUESTION> . . . </QUESTION> sections and parse them. Many other piecesof logic could also be embedded into the templates. The output of theprocessed template is an HTML form that is viewable by the studentcompleting the application. The output from the above template snippetcould look like this, with the special QUESTION tags converted into HTMLform elements and user data incorporated: <H1>BiographicalInformation</H1> <OL> <LI> Please enter your Social Security Number:<INPUT TYPE=“TEXT” NAME=“SS_NUM” VALUE=“200-00-0000” SIZE=11MAXLENGTH=11> </INPUT> </LI> <LI> Please enter your birth date (MMDDYY):<NOBR><INPUT TYPE=“TEXT” NAME=“mdy1_BIRTH_DATE” VALUE=“09” SIZE=2MAXLENGTH=2></INPUT> <INPUT TYPE=“TEXT” NAME=“mdy2_BIRTH_DATE”VALUE=“17” SIZE=2 MAXLENGTH=2></INPUT> <INPUT TYPE=“TEXT”NAME=“mdy3_BIRTH_DATE” VALUE=“1966”SIZE=4 MAXLENGTH=4></INPUT> </NOBR></LI> </OL>

[0083] The above page is then transferred to the user.

Institutions Table

[0084] The Institutions Table includes a row for each institution. Eachrow includes an Institution Identifier, an Institution Name, anidentifier for a parent institution if any, and other information aboutthe institution.

[0085] Institutions can also be arranged in a hierarchy, with oneinstitution belonging to another institution. The Institutions Tableallows the construction of an arbitrary hierarchy of institutions, whichcan be used to control data access. Information in the Contact Table(described below) and Attribute Table is combined with information inthe Institutions Table to determine access to particular attributes inapplications. For example, a financial aid officer in the medical schoolof a university may have access only to financial information on themedical school application, whereas a financial aid officer of theuniversity or of the university system may have access to financialinformation on all applications. Thus, the invention permits flexiblecontrol of data down to the attribute level.

[0086] Institutions can be grouped geographically or by othercharacteristics. The Institutions Table can have fields indicating towhich groups the institution belongs. Thus, the forms engine can controlattributes that are relevant only to institutions in a particular group.

Contact Table

[0087] The Contact Table specifies the database access privileges ofpeople within an institution. For example, an administrator at a stateuniversity system may have access rights to data from applications toall universities within the system, whereas an administrator at aparticular school may have access only to applications to that school.

[0088] Each row in the Contact Table includes a unique ContactIdentifier, an Institutional Identifier, which defines the institutionor group of institutions to which access is granted, and the operationswhich the contact is permitted. For example, a contact may be grantedrights to acknowledge receipt of an application, to transfer applicationdata using a file transfer protocol (FTP), or to receive a printable,non-editable version of completed application.

[0089] The Contact Table can also contain additional useful information,such as the e-mail address or last log-in time for the contact.

Terns Table

[0090] The Terms Table indicates the application terms that arecurrently available. Each row of the Terms Table includes a unique TermIdentifier, a Term Key, the start and expiration dates for applicationsto the institution for the term, a text description of the term, and aninstitution-defined Term Code. The institution-defined Term Code is usedwhen data is uploaded to the institution so that the data is seamlesslyloadable into the institution's information system. TheInstitution-Application Table described below defines the applicationsavailable for each institution and includes a term key field thatidentifies the terms for which the application can be used.

Institution-Application Table

[0091] One institution, represented by a row in the Institutions Table,can own several applications, each of which is represented by a row inthe Institution-Application Table. For example, an institution may haveone application for freshman undergraduate students, another fortransfer undergraduate students, yet another for international students,etc.

[0092] The Institution-Application Table includes one row for eachapplication owned by an institution and relates the information in theApplications Tables to the Institution described in the InstitutionsTable. Each row in the Institution-Application Table includes anApplication Identifier, an Institution Identifier, status of theapplication, type of the application, and information pertinent to theparticular application (i.e., name campus, etc.). Each row also includesa Term Key, which is used with the Term Table to determine which termsare currently available for applying using the application. TheInstitution-Application Table can also include information about theapplication processing fee and how the fee is allocated between theinstitution and the processor.

Transaction Operations Table

[0093] Each time an applicant performs an operation, such as saving apage of information, the operation is assigned a unique OperationIdentification Number and a new row is added to the TransactionOperations Table. Each row of the Transaction Operations Table includesthe unique Operation Identifier, a Transaction Identifier (describedbelow with the Transaction Table), a code indicating which operation therow represents, a contact identifier, and a time stamp indicating thedate and time of the operation. Operations include, for example, save,save and send, acknowledge, secure credit card, no fee, void, and viewprintable application.

[0094] The Transaction Operations Table and the Transaction Tabledescribed below are used to maintain state information.

Transaction Table

[0095] A Transactions Table includes information about each usertransaction, that is, each application that a user has accessed andsaved. Each entry in the Transaction Table includes a unique TransactionIdentifier, a User Identifier, an Application Identifier, a TermIdentifier, and a code indicating the state of the application. TheTransaction Identifier represents a unique combination of UserIdentifier, Application Identifier, and Application Term. There isexactly one row in the Transaction Table for each TransactionIdentifier. The application state can be, for example, ‘in progress’,‘submitted’, ‘payment received’, and ‘acknowledged by the institution,’etc. Each entry also includes an order identifier, a text string thatincludes the User Identifier, the Application Identifier and a timestamp. The Order Identifier is used for credit card settlement and incorrespondence with the institution.

[0096] When a user accesses an application, the universal forms enginelooks for an existing transaction involving the user and the requestedapplication and term. If such a transaction exists, the response of theforms engine to the user depends upon the state of the transaction. Ifno such transaction exist, (i.e., this is the first access to thisapplication by the user) a new transaction is begun. An new entry isinserted in the Transaction Table. A Transaction Identifier is assignedwhen the user requests an explicit save operation or a “save and send”operation for the new application. A Transaction Identifier is notassigned merely on the basis of a page flip on a multipage form.

[0097] Once the user selects the “Save, Pay and Send” button, the Term,Term Identifier and Order Identifier fields are populated, and the stateis set to indicated the application has been submitted. Upon payment, aPayment Operation field is populated with the Operation Identifier forthe payment operation, and the state is set to indicate that payment hasbeen received. This continues as the transaction travels throughsettlement, acknowledgment, etc.

Applicant Pages

[0098] Applicant pages are those presented to the applicant. Theseinclude actual application pages generated by the forms engine anddisplayed with labels identifying the requested information and suitableform data entry elements for applicants to input the requestedinformation. Applications are typically composed of multiple pages.

[0099] Another applicant page shows the applicant the status of allapplications the applicant has worked on. This page is produced by a CGIutility that examines the tables described above and produces an HTMLpage showing whether each application has been completed, saved,submitted, or paid and whether it has been acknowledged by the school.

[0100] Correction pages are presented to the applicant when first orsecond stage validation described below detects missing or incorrectdata.

[0101] Other pages include those that inform the user when no terms areavailable for accepting applications (that is, the current date isoutside the submission windows) or when a requested application hasalready been submitted for the requested term.

Data Validation

[0102] The presence and content of the information is preferably checkedat the server, rather than by the browser on the applicant's computer.This reduces the requirements for the browser, so that the applicant isnot restricted to using the latest version of a browser and, as lesscomputation is performed by the browser itself, compatibility problemsare reduced. An applicant can use a character based browser, such asLynx, if he chooses. When information is recalled from the database forinsertion into a new application, it is checked against the contentrequirements of the institution. If the recalled data does not meet thecriteria, the information is requested again from the applicant.

[0103] Data validation is performed in two stages. Data is saved bothbefore and after each stage of validation. The first stage consists ofchecks that are universal to all applications. These checks are doneevery time a page is submitted, such as when a subsequent page isrequested or when a page is saved. For example, first stage validationmay check that the applicant's name is present, that SAT scores arebetween be 200-800, and that once the non-digit characters are strippedout of social security numbers, a sequence of nine digits not beginningwith “9” or “000” remains.

[0104] To avoid presenting the applicant with an overwhelming number offields that fail validation rules at the end of the entire application,it is preferable to validate as many fields as possible in the firststage validation. On the other hand, the number of required fields ispreferably minimized in the first stage, because an applicant may wantto partially complete an application during one session and complete theremaining fields at another time.

[0105] Second stage validation is performed when an application is beingsubmitted to an institution and the entire form must be complete. Thesecond stage typically includes more required fields and more specificvalidation rules for submitted data fields. Second stage validation isperformed on the entire data set for the application and validates theinformation in accordance with rules specified by the institution forthe particular application. First, institution specific required fieldsare verified. For example, because some institutions may be willing toprocess an application with the field Hobbies left blank, this field isnot required in first stage validation. If an institution does requirethis field to be complete, an incomplete field will be flagged duringsecond stage validation. After second stage validation is successfullycompleted, the data is ready to be uploaded to the institution.

[0106] The Application Table indicates which fields are required for theparticular application. The Application Table also indicates certaindata validation rules, such as permissible values or formats for data.The second stage validation can reformat the data into a formatrequested by the institution. For example, some institutions want thename of the applicant in the form of a single field, with the last namefirst, followed by a comma and then the first name and middle initial.To avoid having applicants enter data more than once to accommodatechanges in format, the information is preferably stored in simpler dataelements, and then combined during second stage validation into theformat requested by the institution.

[0107] Dependency rules are checked during second stage validation. Forexample, whether a particular field, such as Alien Registration Number,is required may depend upon the value supplied by the applicant foranother field, such as Citizenship.

[0108] A user who is earnestly filling out the application with theintent to submit it, could, upon submission, be confronted with manyinstitution-required fields on a large second stage data correctionpage. To minimize the size of that page, the user is given the option ofhaving first stage validation additionally scan the current page'sfields for attributes which will be required by the second stagevalidation process.

[0109] Initially this option is active. If the user is presented a datacorrection page, the top of the page has radio buttons and instructionsfor enabling/disabling this feature. The user's choice is maintainedbetween pages via a hidden field in the form(s).

[0110] In this manner, as the user progresses through the application,he can enter values for second stage-required fields in a gradual mannervia the first stage validation process, rather than being confrontedwith many fields to populate upon submission.

[0111] If the user is unable to supply a value at the time, he candisable this feature and postpone entering data into the field until heis ready to submit the application to the institution.

Attribute Aliasing

[0112] Aliasing of attributes refers to a secondary naming schemedeveloped to create a flexible data dictionary. By using Aliasing, anapplication developer can rapidly locate attributes that are defined bysystem, and avoid creating duplicate attributes that store the samedata.

[0113] Each attribute alias is a series of descriptors delimited bycolons. For example, anything relating to address information uses adescriptor of “ADDRESS”; questions relating to the applicant's birth usea descriptor of “BIRTH”.

[0114] Thus, the country of birth attribute is named “BIRTH₁₃ COUNTRY”but its alias is “BIRTH:ADDRESS:COUNTRY”. Similarly, the date of birthattribute is named “BIRTH_DATE”, and is aliased as “BIRTH:DATE”.

[0115] Permanent address attributes are named “STREET”,“STREET2”,“CITY”,“ZIP”, etc. but the aliases are “ADDRESS:PERMANENT:CITY”,“ADDRESS:PERMANENT:ZIP”, etc.

[0116] Mailing address attributes are named “MAIL₁₃ STREET”,“MAIL₁₃STREET2”, “MAIL₁₃ CITY”, “MAIL_ZIP”, etc. but the aliases are“ADDRESS:MAIL:CITY”, “ADDRESS:MAIL:ZIP”, etc.

[0117] The use of Aliasing provides the ability to search for content bya keyword or set of keywords. For example, to find “father's homeaddress”, one could search for all attributes whose aliases contain thedescriptors “FATHER”, “ADDRESS”, and “HOME”.

[0118] This search would locate the aliases “FATHER:ADDRESS:HOME.1:STREET”, “FATHER:ADDRESS:HOME.1:CITY”,“FATHER:ADDRESS:HOME.1:COUNTRY”, “FATHER:ADDRESS:HOME.1:TELEPHONE”,which correspond to the variable names “PERSON₁₃ AT₁₃ ADDRESS₁₃SINCE.1”, “PERSON₁₃ CITY.1”, “PERSON_COUNTRY.1”, “PERSON₁₃ PHONE.1”,respectively.

[0119] One can look at the intersection or union of keyword searchresults to quickly access desired attributes.

[0120] Thus, the aliasing system is used primarily for developing newapplications: not only as a lookup tool, but also to avoid adding as newvariables attributes that already exist. Finally, aliasing ensuresmaximum data-sharing by weeding out duplicates that would split the databetween two name spaces. It is preferable to use this system as theprimary internal naming scheme.

Procedure

[0121]FIG. 16 shows the steps that occur in a preferred embodiment whenan applicant contacts the forms engine. Step 156 shows that when anapplication contacts the URL of the forms engine, the forms engine isinvoked and initializes itself by reading in libraries and initializingvariables, such as global constants and data structures. For example, inthe first embodiment of the Application Data File described above, anassociative array of associative arrays that defines the form elementsused by the engine to construct the application form is initialized.

[0122] In step 157, the forms engine looks for data posted from the Webpage form. There may be no data at first, but after some information isentered and a page is saved or changed, data will post to the formsengine, which will perform first stage validation on the data. The formsengine then processes input arguments and posted data to determine theapplication state as described below.

[0123] Step 158 shows that the forms engine then makes database calls toinitialize variables pertaining to the current admissions application(ID #, fee information, institution, etc.).

[0124] Step 159 shows that the forms engines determines whichapplication terms (e.g. “Fall 1999”, etc.) are available for thisuser/application combination. For example, the user may have alreadysubmitted and paid for a “Fall 1999” application and is now requestingthe same application. This request may be to 1) review the submittedapplication or 2) apply for a new term. The engine needs to guaranteethat the user does not submit the same application more than once perterm. The search engine calculates submission state information toprevent a user from changing data in an already submitted application,and then resubmitting it in the mistaken belief that the data would beupdated at the institution.

[0125] There are three outcomes of the calculation of submission state:

[0126] a. No currently available terms. Each term has a Begin-Date andan Expiration-Date. If the current time is before the Begin-Date orafter the Expiration-Date, that term is unavailable. No terms would beavailable if all application windows for an institution are eitherexpired or have not yet begun, or if the user has applied to allcurrently available terms.

[0127] b. User has applied for a term, and has not yet initiated a newtransaction for this application.

[0128] C. User has an available “Active,” that is, not submitted orpaid, transaction for this application.

[0129] In step 160, the engine determines, based upon the availabilityof a term and the state of any pending or submitted applications, whichapplication form is required by the user and generates the appropriateapplication form. If the user has an available active transaction, theengine will return the appropriate page of the application in an HTMLform with any previously supplied data already filled in. If the userhas already submitted the application and has no active transactions, an“Already Submitted” page is returned, with hypertext link(s) to“Printable” (uneditable) versions of the submitted application(s), andthe option to fill out the application for a term other than the term(s)already applied for. If there are no available terms, a “No AvailableTerms” page is returned, which gives the user the option to fill out andsave the application, but not submit it until a term is available. Inthe case that the user has previously submitted an application for thespecified term and no other terms are available, a hybrid of the abovetwo pages is returned, with links to printable version(s) of submittedapplication(s) and the option to fill in and save data but not submitthe application until a new term is available.

[0130] In step 161, the forms engine reads and parses the “ApplicationData File” corresponding to the application to find the appropriate pageof the application.

[0131] In step 162, the engine initializes a user data structure,preferably an associative array of key/value pairs or a data object inan Object-Oriented implementation Programming using data from the UserAttribute Table.

[0132] If data has been posted, the forms engine performs first stagedata validation in step 163.

[0133] If one or more data fail validation, the engine creates a “datacorrection page” and returns it to the user. This page repeats the textof the failed question, displays a message explaining why the datafailed, and repeats the form element pertinent to that datum. When theuser posts this page, first stage validation is applied to the incomingdata, and if one or more are still in error, a new data correction pageis returned. This process continues until all the data for that pagehave passed validation.

[0134] As described above, the first stage validation optionally checksfor second stage required fields, thereby reducing the number of fieldsthat will require data entry during the second stage validation. On eachdata correction page, the user has the option to enable/disable thisfeature.

[0135] In step 164, the forms engine outputs an appropriate page to theuser depending upon the engine's state.

[0136] The front end, that is, the portion of the forms engine thatprocesses incoming data from the user, is essentially one CGI programthat determines the proper action by parsing information coming in fromthe Web form in combination with state information from the TransactionsTable. For example, the user could be returning from a data correctionpage, the user may have hit the “save and send” button, or the user mayhave switched pages. The engine may look for posted data and process it,etc.

State

[0137] The forms engine can be in one of several possible states afteranalyzing incoming data. For example, the data may have failedvalidation and the forms engine, therefore, needs to output datacorrection page, or a user may have requested to go to page “x”, so theforms engine needs to create and output page “x”; etc. (see discussionof state, below).

[0138] Most interactions between the user and the inventive system arethrough “front-end processing,” which was described above with respectto FIG. 14. The response of the engine is dependent upon the currentstate. The Web, which is the communications conduit the system uses, isby definition stateless: When a browser (Web client) submits a requestto a Web server, a connection is made between the two only long enoughfor the server to transmit the desired information. The server thendrops the connection, and any information created by the client/serverinteraction is discarded by the server. The next time the clientconnects to the server, the slate is blank and they start thatinteraction from scratch.

[0139] The system needs a way to maintain state information betweencontacts. The system utilizes two state models to describe the states oftwo different aspects of the system: a “session state” applies to thefront-end process of creating and returning Web forms, and a“transaction state” pertains to the state of the transaction, that is,the state for a particular user's application to an institution for aspecific term. Transaction states include for example, active orsubmitted or paid or void.

[0140] Every page has hidden fields that provide state information. Thesession state can be determined by parsing the hidden fields returnedwith data. State information can include, for example, the versionnumber of the application and the page that the user previouslyrequested. For example, the hidden fields would indicate to the serverwhether a page is being returned because the applicant selected “Save,Pay, and Send” or whether the applicant merely requested a page flip. Asanother example, when first stage validation finds an error and returnsa data correction page to the user, the data correction page includeshidden fields that indicate the page that the user was attempting to goto. When the data correction page is submitted, the engine parses thehidden fields to determine the state and returns the previouslyrequested page to the user.

[0141] The current transaction state for a specific application/usercombination is determined by looking up the application in the data basetables described above. For example, if the applicant requests anapplication for a term for which the applicant has already submitted anapplication, the engine determines that such is the case, and ratherthan returning the application, returns a page stating that theapplication was already submitted. The student is given the option ofviewing the application in a printable, non-editable form, or of openingan application form for another term. The engine screens out the termalready applied for when it returns the application. If no terms arecurrently available, a page is returned that states no terms arecurrently available, but the applicant is permitted to begin completingan application that can be saved until a term is available. In such acase, the “save and send” button is not available until a term isavailable. Thus, applicants can begin completing forms even before aterm is available.

[0142] With regard to the front-end state model, the following is a listof the states the engine defined by the action that caused the engine tobe in that state:

[0143] 1. “Initial Contact”—The user is requesting the application formfrom outside of the engine. The engine will create the first page of theapplication, merge any matching user data, and return the form.

[0144] 2. “Page Flip”—For multi-page applications, the user has comefrom page “x” and wants to go to page “y”. The engine first appliesfront-end validation to the incoming data posted from page “x” (whichmay result in returning a data correction page), saves the validateddata, generates page “x”, merges any matching user data and returns theform.

[0145] 3. “Explicit Save”—At the bottom of each page is a button thatallows them to save the current page of data. Essentially, the action ofthe engine in this state is identical to the “page flip”, but “x” equals“y” (i.e., the returned page is the same page number as the page postedfrom).

[0146] 4. “Save and Send”—The user has elected to submit the completedapplication to the institution. The engine does front-end validation onthe current page posted, saves data, does back-end validation on alldata pertaining to the application, saves data to the User AttributeSent Table, and passes control to the payment server.

[0147] 5. “Data CRX (Correction) Page”—When either front-end or back-endvalidation has failed, the engine switches to this state, which causesthe form generator to create a data correction page and hide in thatpage state information including the state the engine was in prior toswitching to this state. (For example, if the user is on page 3 andchose to go to page 5, but errant data on page 3 lead to an interveningdata correction page, the data correction page includes hidden dataindicating the page flip to page 5). Once the data are successfullyamended and the user posts the data correction page, the engine detectsthat the prior state was a “page flip” to page 5, and returns page 5 tothe user. Similarly, if the user had selected “save and send” and got anintervening front-end or back-end validation data correction page, oncecorrected the post from that data correction page will then switch theengine into “save and send” mode, and the user will receive the paymentpage from the payment server.

[0148] 6. “App Terms Page”—This state is entered when the applicantrequests an application that was already submitted or for which no termsare available: (a) an “already submitted” page; or (b) a “no availableterms” page. The engine will return either with hidden stateinformation. When one of these pages is posted, the engine will thencontinually insert additional hidden state information into subsequentforms to ensure future behavior is in accordance with selection(s) theuser made on those pages.

[0149] 7. “Print Engine”—The engine is being called in print mode todeliver a “printable” (i.e., non-form) version of the application/userdata.

[0150] 8. “Exit”—The user has chosen the ‘Finish Session’ button on theapplication page, and the engine passes control to the user activityCGI, which displays a page of information about the applications theuser has worked on and their status.

[0151] 9. “Search”—The user has selected a search button to aid in theselection of a value for example, a country. The engine saves anyvalidated data and displays a search page, which contains links back tothe page of the application the user left. These links also cause theselected value to be passed into the engine, which then displays itappropriately in the form.

[0152]FIG. 17 shows the back-end state model for an application, and thecorresponding transaction operations that cause changes between states.Null state 172 is the state after an application has been created butbefore the application has been posted by the applicant. The applicationswitches into the active state 178 when the applicant saves a page ofthe application or when the applicant attempts to save a page and anerror prevents the page from being saved. When the application issubmitted, it enters a submitted state 180. The applicant is preferablygiven a warning that no changes can be made to the application afterpayment is made and is given the option to amend the application. If theapplicant indicates a desire to amend the application, or if theapplication fee is not paid, the application returns to active state178. If the applicant request a fee waiver or the applicant indicatesthat he desires to pay by check, the application enters a hold state 182until the check clears or the fee waiver is approved by the institution.Fee waivers are used by institutions to encourage applications fromqualified individuals who may not be able to afford the application fee.

[0153] After the application is submitted, the applicant pays for theapplication, which enters a paid state 184 until the payment isacknowledged by the institution or settled. In the paid state 184 andsubsequent states, the application can be viewed for printing by theapplicant or downloaded by a batch transfer or file transfer protocol bythe institution. The application is then acknowledged by the institutionand the payment is settled. Depending upon whether the acknowledgment orsettlement occurs first, the application enters an acknowledged state186 or a settled-preacknowledgment state 192. After both settlement andacknowledgment occur, the application enters a completed state 190. Theapplication can enter a void state 194 if it becomes unuseable, forexample, because an applicant cancels the application or withdrawspermission to provide the application information to the institution.Voided application are maintained in a separate database table.

Data Formatting

[0154] When application information is uploaded and acknowledged by theinstitution, the original application information remains archived inthe applicant database in the User Attributes Sent table. Theapplication can be printed, re-uploaded, etc. Institutions can requestinformation related to all or a subset of their applications to see, forexample, what new applications have been sent and the status of variousapplications. The data is available for data manipulation, such as forsorting on fields or presenting application information in variousdatabase views. For example, a school can look at applications sorted bytest scores. The school could also look at all applications of studentsfrom a particular geographical area, or students who play a particularsport or instrument. The institution can perform statisticalcorrelations between information on the application and grades achievedat the institution after matriculation to determine what characteristicsof applicants correlate with success at the institution.

[0155] Not only are the individual data elements tailored to thespecifications of a particular institution, the entire data set isformatted to conform to that institutions needs. The data formats mayinclude 1) comma separated values, 2) tab delimited values, 3) fixedlength formats, 4) name/value pairs, and 5) EDI 189. For all of thesemethods, of course, the data is ordered as required (e.g., SocialSecurity number first, last name second, high school name 33rd, etc.).

[0156] The format of the entire data set is done via back-end utilitiesthat run on the server and that utilize specially formatted text filescontaining data formatting descriptions and additional data-manipulationrules. These utilities are triggered when the institution's contactperson accesses the administrative utility on the forms engine serverand chooses to upload data sets.

[0157] Another implementation of the invention uses object-orientedprogramming and the Extensible Markup Language (XML), which is used tocreate a customized mark-up language related to applications processing.In this embodiment, most of the information about each applicant isstored in an XML file corresponding to that applicant, although somebasic account information about each applicant is still maintained in adata table. Information about each application is stored in an XMLapplication description file. This implementation requires fewer files,thereby simplifying maintenance and reducing the run time overheadassociated with reading and reconstructing applications from multiplefiles. First and second stage validation rules are maintained in the XMLapplication description file. Unlike the previously describedembodiment, initialization is only required when the web server isstarted, because the application persists, along with its databaseconnections, as long as the server is operating.

[0158] An XML parser, typically written in Perl, parses the XMLapplication description source file and invokes programs that implementby creating and saving binary objects the features specified by the XMLtags. For example, the text between a <begin page> tag and an <end page>tag is used to create a page object having attributes defined by thetext between the tags. Similarly, an object corresponding to an elementof a page is created based upon the text between a <begin element> tagand an <end element> tag. The created objects define the applicationthat is presented to the applicant.

[0159]FIG. 18 shows examples of binary objects created by the XML parserand the relationships between some of the objects. For example, FIG. 18shows, that a page object 204 can include one or more element object206, groups objects 208, and table objects 210. An element object 206,which can be instantiated for example as a question on the application,includes a pre-text element 212 and a post-text element 214corresponding to text associated with the question, an input fieldelement 216, and any validation rule elements 218. Groups objects 208may also include a pre-text element 212 and a post-text element 214, aswell as element objects 206, other group objects 208, and table objects210. Table objects 210 can include table header objects 220 and rowelement objects 222. Skilled programmers can write many classes tocustomize an application and will understand that FIG. 18 is a greatlysimplified example used to demonstration the principles of theembodiment.

[0160] The group object allows multiple elements to be associated with agroup and eases the implementation of an adaptive application, in whichthe content of application pages sent to an applicant may depend uponthe applicant's answers in previous pages. Whether an element or groupis displayed depends upon the value of a display attribute, which can beused to specify the conditions under which the object is displayed onthe screen or in printed reports. For example, a group of questions maybelong to a “non-U.S. citizen” group object. Questions belonging to thenon-U.S. citizen group object may request information such as visa type,alien registration number, and country of origin. If the applicantanswers that he is a U.S. citizen, elements in the “non-U.S. citizen”group are not displayed. An adaptive application would also be usefulfor a higher education system that includes multiple schools orcampuses. A single application file could be used, with the questionspresented to the applicant depending upon the particular school theapplicant chooses. Using a single application greatly simplifiesmaintenance of the application form.

[0161] Applicant information is similarly saved in an applicant XMLfile. Unlike the application description XML file, the applicant file ischanged as information is posted by the applicant. Thus, the applicantXML file is re-saved each time that data is posted by the applicant.

[0162] Although the present invention has been described using anembodiment that processes college admission application forms, it is notlimited to that application, but is applicable to processing any form,such as employment forms and student loan forms, such as for the PLUSstudent loan program While a preferred embodiment of the presentinvention has been shown and described, it will be apparent to thoseskilled in the art that many changes and modifications may be madewithout departing from the invention in its broader aspects. Because thecomputer and computer network fields are changing rapidly, it isexpected that implementation of the invention will change significantlyas technology evolves. The particular programming language and the typeof database can be varied depending on the preferences of theprogrammer. Such changes in implementation, however, do not depart fromthe spirit and scope of the invention. The appended claims are thereforeintended to cover all such changes and modifications as fall within thetrue spirit and scope of the invention.

1. A method of creating and processing over a computer network formsrepresenting applications for admission to different institutions,comprising creating in response to a request from an applicant for anapplication to a first institution a first application form customizedin accordance with the preferences of the first institution, the firstapplication form including data fields for entering applicantinformation; providing to the applicant over a computer network thefirst application form; entering the applicant information in the datafields; posting the first application form to a server; storing theapplicant information in a data storage; creating in response to arequest from the applicant for an application to a second institution asecond application form customized in accordance with the preferences ofthe second institution, the second application form including datafields for entering applicant information; inserting into some of thedata fields of the second application applicant information from thedata storage; providing to the applicant over a computer network thesecond application form; entering applicant information into the datafields for entering applicant data into which information was notinserted from the data storage or into which the data inserted from thedata storage is to be changed; posting the second application form tothe server, whereby customized applications to different institutionsshare data through common data storage.
 2. The method of claim 1 inwhich creating a first application form customized in accordance withthe preferences of the first institution includes generating a firstapplication in accordance with stored application descriptioninformation and in which the first application can be modified bymodifying the application description information without rewriting thecomputer program that creates the application.
 3. The method of claim 1in which posting the first application includes verifying thatpre-specified application information is present and meets pre-specifiedcriteria.
 4. The method of claim 1 in which posting the firstapplication and posting the second application each includes the stepsof posting a single page of the application and of posting the completedapplication, and in which posting a single page includes verifying thatsome specific information is present and meets pre-specified criteriaand in which posting the complete application includes verifying thatthe information meets criteria specified by the correspondinginstitution
 5. The method of claim 1 in which creating an application toa first institution includes creating an application identified with thebrand of the first institution and in which creating an application to asecond institution a second application includes creating an applicationidentified with the brand of the second.
 6. The method of claim 1further comprising transmitting the applicant information to the firstinstitution in a format specified by the first institution andtransmitting the applicant information to the second institution in aformat specified by the second institution.
 7. The method of claim 6further comprising making multiple applications to the first institutionfrom different applicants available on line to the first institution foranalysis after transmitting the applicant information to the firstinstitution.
 8. The method of claim 7 in which making multipleapplications available to the first institution includes makingapplication information selectively available to various personnel atthe institution.
 9. The method of claim 1 in which storing the applicantinformation is performed by a third party application servicer.
 10. Themethod of claim 9 in which posting the first application and posting thesecond application includes paying application fees for the applicationsand in which the third party servicer processes the application fee. 11.The method of claim 1 in which storing the information includes parsingthe information into elements, the data elements being separately storedand identified, thereby allowing the elements to be separately retrievedand rearranged in subsequent applications.
 12. The method of claim 11 inwhich inserting information from the data storage includes insertinginformation representing combined elements into a single field.
 13. Themethod of claim 1 in which the fields for entering applicant informationinclude labels and in which at least some of the fields in the secondapplication use different labels different from those in thecorresponding fields in the first application, and in which storing theapplicant information and inserting applicant information from the datastorage is independent of the labels used in the application, therebyallowing each institution to customize the appearance of itscorresponding application, while still permitting information to beshared across applications.
 14. The method of claim 1 in which thefields for entering applicant information are formatted and in which atleast some of the fields in the second application are formatteddifferently from those in the corresponding fields in the firstapplication, and in which storing the applicant information andinserting applicant information from the data storage is independent ofthe format used in the application, thereby allowing each institution tocustomize the appearance of its corresponding application, while stillpermitting information to be shared across applications.
 15. The methodof claim 1 in which providing the first application form comprisesproviding multiple pages and in which posting the first application to aserver includes posting multiple pages to the server.
 16. The method ofclaim 15 in which the content of a page of the provided applicationdepends upon information posted in a previous page.
 17. The method ofclaim 1 in which the data storage includes a relational database or XMLfiles.
 18. The method of claim 1 in which the data storage includesstores metadata describing the data.
 19. The method of claim 17 in whichthe metadata includes validation rules for the data.
 20. The method ofclaim 17 in which the metadata specifies the sharing betweenapplications or the accessibility of the data.
 21. A system for creatingand processing customized forms for unrelated institutions using acommon third party data storage over a computer network, the systemincluding: a server computer operated by the third party and in datacommunication over a data network with a client computer for requestinga form and for entering information onto the form; first data storage incommunication with the server computer and including form descriptioninformation specifying the content and appearance of each customizedform; second data storage in communication with the server computer andincluding in a user information posted from the client computer; and aforms engine program operating on the server computer for generating aform from the form description information in response to a request forthe form transmitted from the client computer over the computer network,the form including fields for user information, the forms engine programpopulating the fields for user information with user informationavailable from the second data storage, accepting information entered onthe form by the user, and storing the newly entered information in thesecond data storage for use on subsequent forms.
 22. The system of claim20 in which generating a form includes generating a form includingbranding information identifying the particular institution to which theform is directed.
 23. The system of claim 20 in which the customizedforms include labels for data entry fields and in which labels aredifferent for the same user information on different ones of thecustomized forms.
 24. The system of claim 20 in which the same userinformation is requested using different styled menus on different onesof the customized forms.
 25. The system of claim 20 in which at leastsome of the user information is parsed into smaller elements beforestorage, the smaller elements individually retrievable for insertioninto subsequent forms.
 26. The system of claim 20 in which theinformation about the user is in the form of user attributes and inwhich user attributes have properties that specify information about theattribute.
 27. The system of claim 20 further comprising means fortransmitting in a format specified by the institution information from acompleted form to the institution associated with the form.
 28. Thesystem of claim 20 further comprising means for verifying information ina form, the verification means including means for verifying informationcommon to all forms and means for verifying information for a specificinstitution.
 29. The system of claim 20 in which the forms enginegenerates a form comprising multiple pages and in which the content ofat least one of the multiple pages depends upon previously supplied userinformation.
 30. The system of claim 20 in which the first or seconddata storage comprises one or more XML files stored on a computerreadable medium.
 31. The system of claim 20 in which the first or seconddata storage comprises one or more relational database tables stored ona computer readable medium.
 32. A method of creating and processingforms associated with multiple institutions, comprising: contacting aserver over a computer network; creating a form customized for one ofthe multiple institutions from stored form description information;inserting available user information from a user data storage into theform; transmitting the form with the available user information to auser for completion; completing the form; receiving the completed form;and storing user information from the form in the user data storage. 33.The method of claim 31 in which completing the form includes completingmultiple pages of the form with each page being transmitted to theserver for verification in accordance with verification rules beforecompleting a subsequent page.
 34. The method of claim 32 in whichreceiving the completed form includes verifying the completed form inaccordance with verification rules specific to the one of the multipleinstitutions.
 35. The method of claim 31 in which the user data storageincludes a relational database.
 36. The method of claim 31 in which theuser data storage includes a one or more XML files.
 37. The method ofclaim 31 in which the user data storage includes information describingproperties of the data.
 38. The method of claim 36 in which theproperties of the data include permissible values for the data.
 39. Themethod of claim 36 in which the properties of the data specify theconditions under which the data is to be displayed.
 40. A formsprocessing apparatus, comprising: multiple forms for containing data,the forms being associated with different institutions and specifying aprocess, the process including a front-end process for presenting a pageto a user and receiving and storing data from the user and a back-endprocessing specification for preparing the form data for receipt by theinstitution; a forms engine that integrates the form, the data, andprocesses regardless of the appearance of the form, the type orsignificance of the data, and the processing that follows collection ofthe data.
 41. The method of claim 39 in which the forms engine resideson a server maintained by a third party forms servicer and each form iscustomized for an associated are specified in a relational database. 42.The method of claim 39 in which the content and processes of the formsare specified in XML files.
 43. The method of claim 39 in which thefront end processing includes data validation.
 44. The method of claim39 in which the front-end processing includes creating a form includingmultiple pages, the content of each page dependent upon informationpreviously supplied by the user.
 45. A method of providing customizableapplications to institutions, the applications sharing common datastorage, the method comprising: providing at least two applicationinformation files, each describing a customized applications for anindependent institution; providing data storage for storing informationentered on an application and inserting the information into subsequentapplications; generating a customized application in response to arequest over a computer network from an applicant, the application formand content being specified by one of the at least two applicationinformation files; populating fields of the customized application usinginformation from the data storage; transmitting the customizedapplication over a computer network to a requesting applicant; andcompleting fields of the application that were not populated from thedata storage.
 46. The method of claim 44 in which completing fields ofthe application that were not populated from the data storage includingoverwriting with new values fields that were populated from the datastorage, the new values being stored in the data storage in place of theexisting values.
 47. The method of claim 44 in which providing a datastorage for storing information includes providing a data storage thatis extensible without reprogramming the program for generating thecustomized application, thereby allowing an institution to readilyrequest and store new information not previously stored.
 48. The methodof claim 44 in which generating a customized application includesgenerating an application that includes the logotype of the institution.49. The method of claim 44 in which the data storage store metadatadescribing the data.
 50. The method of claim 48 in which the metadatadescribes permissible values for the data and further comprisingcomparing the data in the completed fields with the permissible values.51. The method of claim 48 in which the meta data describes conditionsunder which questions on the customized application are displayed. 52.The method of claim 44 in which the data storage includes a relationaldatabase.
 53. The method of claim 44 in which the data storage includesone or more XML files.
 54. The method of claim 44 in which thecustomized application includes multiple pages.
 55. The method of claim53 in which the content of one of the multiple page depends the fieldscompleted by an applicant on a previous one of the multiple pages.